I haven't tried this out to have real-world experience to report, but I'm a bit wary of the behavior of ignoring file updates if a type check is in progress. I'm often working in a scratch file that takes several seconds to type check, and if my saves start getting ignored without noticing, I could see it being a really bewildering experience. And in the worst case I might never push code that I think that I have pushed.

I agree that queuing up additional type checks that don't start until the first one finishes is not useful. But I wonder if getting rid of the queue should hold off until the improvement that you mentioned has been implemented:

We might instead want to interrupt a typecheck on file change, so that we don't waste time typechecking an old thing, and can just start over with the latest contents.

@ceedubs Ok, I've made that change. I agree it's better than just leaving it up to the user to realize they last saved their file while a typecheck was in-progress, and they therefore might be looking at an old typecheck result.

Would you mind trying this branch out and report whether it works as you'd like it to?

Thanks @mitchellwrosen!

Here is an example that I tried. clone @unison/cloud and then edit.namespace. For me each save of my scratch file takes about 40 seconds for ucm to catch up. (Side note: I think that a lot of that time might be spent rendering test results for tests that have already been cached.) Obviously this isn't ideal, but most of the time you probably won't have this much code in your scratch file. BUT a concern for me is whether this might result in basically an endless loop for people who use editors that auto-save files every 5 seconds (or whatever). Will those save again if the file contents haven't changed? And if so will that restart the 40 second file change event? If so, I don't think that there will be any feedback to the user letting them know that they are in an endless loop as opposed to a single file save event. But I'm probably not understanding how this works for people with auto-save editors.

@ceedubs A typecheck is only aborted and restarted if the file contents actually change. (Were you observing otherwise?)

Note that the trunk behavior is also not good for a person trying to typecheck a file that takes 40 seconds, with an editor that's auto-saving every 5: a never-ending stream of old typechecking results!

Were you observing otherwise?

I wasn't sure. As far as I can tell there isn't any feedback that the type checking is restarting. Which is probably fine.

A typecheck is only aborted and restarted if the file contents actually change.

Okay great! 👍

I wasn't sure. As far as I can tell there isn't any feedback that the type checking is restarting. Which is probably fine.

Oh, hm, you should see this again, which we output before parsing:

Loading changes detected in ~/scratch.u.

Eek, interruption doesn't seem to be working, actually. I guess I need to debug this further.

Sorry for the thrash, I had an obvious bug, now I feel this PR is doing the right thing. And yeah, if you interrupt one long typecheck with a new one, you will see a repeat of the "Loading changes" message, which indicates we've started over.

One changed behavior I noticed is if you save a blank .u file when ucm is first opened, it doesn't generate any output.

Usually I do this to confirm that the file is "connected" e.g. not the right name in the wrong directory for my ucm session; I'm open to alternative methods though.

Is there an easy fix for that?

Huh, I can't reproduce now; that was weird.

Now I can reproduce again. 🤷‍♂️

I can only sometimes reproduce it.

Could you try to too @mitchellwrosen

@aryairani I'm not seeing any difference in behavior between trunk and this branch with respect to saving an empty file. (And furthermore I can't think of anything in the implementation that might have affected that, but I could be forgetting something).

Can you think of anything that would make the cli tests time out on windows? I'm rerunning them optimistically

@aryairani Hmm...

I got this with git bisect and the command

stack run unison -- run.file unison-cli-integration\integration-tests\IntegrationTests\print.u print --codebase-create tempcodebase

0abf9e2 is the first bad commit

commit 0abf9e230110efd617a0450cdce04ee5e3103b1f
Author: Mitchell Dalvi Rosen <[email protected]>
Date:   Fri Mar 21 14:10:36 2025 -0400

    rework filesystem event handling so that events aren't queued

 unison-cli/src/Unison/Codebase/Watch.hs   | 226 +++++++++--------------
 unison-cli/src/Unison/CommandLine/Main.hs | 285 ++++++++++++++++--------------
 2 files changed, 234 insertions(+), 277 deletions(-)

Here's the line we ended up with:

stopListening <- unsafeUnmask (FSNotify.watchDir mgr dir (const True) handler) <|> pure (pure ())

Do you wanna just cherry-pick it into the latest?